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This paper discusses the GReTL solution of the TTC 2011 Compiler Optimization case flj. The 
submitted solution covers both the constant folding task and the instruction selection task. The 
verifier for checking the validity of the graph is also implemented, and some additional test graphs 
are provided as requested by the extension. 

1 Introduction 

GReTL (Graph Repository Transformation Language, Q) is the operational transformation language of 
the TGraph technological space O. Models are represented as typed, directed, ordered, and attributed 
graphs. GReTL uses the GReQL (Graph Repository Query Language, [3 |) for its matching part. 

The standard GReTL operations are currently targeted at out-place transformation which create the 
target metamodel and the target graph simultaneously, but this case requires changing the graph in-place. 
Luckily, GReTL is designed as an extensible language. Adding custom operations requires only spe- 
cializing one framework class, overriding one method that implements the operation's behavior, and 
implementing another factory method that is responsible for creating an instance of the new operation 
initialized with the given parameters. Consequently, some in-place operations have been added to the 
language. There is one operation MatchReplace which is similar to a rule in graph replacement sys- 
tems. There is an operation Delete for deleting elements, an operation MergeVertices for merging a set 
of duplicate vertices into one canonical representative, and a higher-order operation Iteratively which 
receives another operation and applies it as long as possible. The implementation of the most complex 
one, MatchReplace, is about 380 lines of Java code including comments and empty lines, the other three 
operations are at most 80 lines or less. Thus, this case was solved using a mixed bottom-up and top-down 
approach: the language was extended with three new operations, and then these operations were used to 
write the transformations. 

2 Case Solutions 

In this section, the two transformation tasks are discussed in sequence. The solutions can be run on the 
SHARE image iffl. 

2.1 Constant Folding 

The GReTL solution for the constant folding task does a bit more than what was required. It contains 
operation calls that realize the following optimizations: 
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(1) Binary operations depending only on two Const vertices are replaced with with a Const containing 
the result of evaluating the binary. 

(2) Not operations depending only on a Const are similarly replaced by the evaluation result. 

(3) Unused Const vertices are deleted. 

(4) Const vertices representing the same value are merged into one. 

(5) Cond nodes (conditional jumps) depending on a Const are replaced with unconditional jumps (Jmp). 

(6) Unreachable code is eliminated. 

(7) The operand edges of Phi vertices are renumbered if needed. 

(8) Phi vertices with only one argument are replaced by a direct dependency between the argument and 
the vertex depending on that Phi. 

(9) Block vertices containing only an unconditional Jmp are removed. 

(10) In subgraphs consisting of commutative and associative binary operations (Add or Mul) constants 
are pulled up in order to generate new possibilities for the constant folding optimization (1), e.g., a 
graph structure ((1 *x) *2) is replaced with ((1*2) for ★ G {+, *}. 

In the following, the optimizations (1), (3), and (4) are discussed, starting with the evaluation of 
binary operations depending only on constants. A helper function is defined that receives some Binary 
operation bin and the values of its left and right operand (Ival, rval) and returns the evaluation result. 

evaluateBinaryO := using bin, Ival, rval: 

/jasType{Add}( bin ) ? Ival + rval 

: has Type{ Sub }( b i n ) ? Ival — rval 

: has Type{ M ul }( b i n ) ? Ival * rval 

; hasTypej Div }( bin ) ? (let d := Ival / rval in d < ? ceil(d) : floor(d)) 

: /jasType {Mod}( bin ) ? Ival % rval 

: /jasTypejshl }( bin ) ? bitOp (" SHIFT_LEFT" , Ival, rval) 

: /jasrype{Shr}( bin ) ? bitOp (" UNSIGNED_SHIFT_RIGHT" , Ival, rval) 

: /)asrype{Shrs}( bin ) ? bitOp (" SHIFT.RIGHT" , Ival, rval) 

: />asrype{And}( bin ) ? bitOp("AND", Ival, rval) 

: /jasrype{Or}( bin ) ? bitOp("OR", Ival, rval) 

: /jasrype{Eor}( bin ) ? bitOp("XOR", Ival, rval) 

: has TypejCmp} ( b i n ) ? 
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error {" Don ' t know how to handle " ++ bin . relation )) 
error("Don't know how to handle " ++ bin); 

Depending on the type of the given Binary bin, the correct operation is dispatched using a sequence 
of conditional expression^ and applied to the operand values. The division has to be handled specially: 
in GReQL, a division results in a double value, but here an integer division is intended. To match these 
semantics, either the floor or the ceiling of the result d is taken. 

The next listing shows the replacement of all Binary vertices that have two Const arguments with a 
new Const with value set to the result of evaluating the binary operation. The MatchReplace operation 
has semantics similar but not identical to rules in graph replacement systems. Its first parameter is a 
template graph that describes the structure of the subgraph to be created or changed (similar to the RHS 
in rules in graph replacement systems), and following the arrow symbol, there is a GReQL query that 
reports a set of matches. The query is comparable to the LHS in graph transformations, except that it 



GReQL conditional expression: <testExp> ? <trueExp> : <falseExp> 
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calculates all matches instead of one match at a time. For all matches, the template graph is appUed, 
thereby skipping matches containing previously modified elements. 

In the template graph, the dollar ($) is a variable that holds the current match. Vertices are represented 
using paretheses and edges with arrows and curly braces: 

(Type 'greql' | attrl = 'greql2', attr2 = 'greql30 
~>{Type 'greql' | attrl = 'greql2', attr2 = 'greql3'} 

The semantics for vertices, but likewise for edges, are as follows. The optional Type is a vertex type 
name. If no Type is specified and greql evaluates to a vertex in the current match or any other vertex 
in the graph, it is bound to the template vertex and preserved. If Type is given and greql evaluates to a 
vertex in the current match, then that vertex is replaced with a new vertex of the specified type, all edges 
incident to the replaced vertex are relinked to the new one, and the new vertex is bound to the template 
vertex. If Type is given but no greql query, then a new vertex of the given type is created and bound 
to that template vertex. The attributes of the bound elements are set to the result of the queries in the 
attribute list. All vertices and edges in the match that are not bound to any template graph element are 
deleted. The deletion of some vertex implies deletion of all incident edges. 

Iteratively MatchReplace ('startBlock ') < — {Dataflow | position = ' — 1'} 

(Const '$.op' I value = '$. value') 
<= from binOp: \/{ Binary} 

with /)asType{ Const }( I CO n St ) and hasrype{ Const }( rco n st ) 
reportSet rec(op: binOp , 

value: e v a I u a t e B i n a r y ( bi n Op , I c o n st . va I ue , rconst . va I ue ) , 
edges: edgesFrom {h\nOp )) end 
where argEdges := so rt By Pos i t i o n ( non Conta inmentDfs ( binOp ) ) , 
Iconst := end\/ertex( argEdges [0] ) , 
rconst -•= enrfVertex( argEdges [ 1] ); ; 

The higher-order operation Iteratively applies the MatchReplace operation as long as some match 
could be replaced. The query given to MatchReplace reports a set of matches where each match is a 
record of a binary operation (op), the evaluation result gathered by the evaluateBinary() helper (value), 
and the set of edges starting at the binary operation (edges). 

The template graph specifies that a Const has to be created with value set to $.value. The new Const 
should be connected to the StartBlock. The connecting edge has to be of type Dataflow with position — 
-1. Because the new Const refers to the binary operation op and additionally specifies a type, it means 
the replacement of that binary with the new constant. All edges incident to the binary will be relinked to 
the constant. Finally, the binary op and all edges starting at it will be deleted, because they occur in the 
match but not in the template graph. 

This operation may have deleted vertices that were the single element depending on some Const. 
Thus, the following operation deletes all unused Const vertices. 

Delete <= from c: VfConst} with inDegree{c) = reportSet c end; 

Furthermore, the operation may have created duplicate Const vertices, i.e., constants with the same 
value. The next operations merges them in order to have exactly one Const per needed value. 

MergeVertices <^= from const: V{Const} 

reportMap const — > from d: V{Const} 

with d. value = const. value and d O const 
reportSet d end 

end ; 

The MergeVertices operation receives a query that has to result in a map assigning to vertices a set of 
duplicates that should be merged. Any Const vertex is mapped to the set of all different Const vertices 
with equal value. Thus, for any used value there will be exactly one canonical Const. 
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2.2 Instruction Selection 

In this section, all operation calls for the instruction selection task are discussed. The first one transforms 
all Binary vertices with at least one Const argument to immediate target binary operations. 



MatchReplace (#"' Target" ++ tYpeName{S . binary ) ++"!"' '$ 


. binary ' 


1 value = '$. value ',...) 


<= from b: \/{ Binary} 






with coun t ( CO n St Ed ges ) > 






reportSet rec(binary: b, 
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edge: co n st Ed ges [ ] ) end 
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)) 




reportSet e end; 







The query iterates over all Binary vertices that depend on at least one constant. The variable con- 
stEdges is bound to all Dataflow argument edges leading to a Const with one additional restriction: if 
the binary operation is not commutative, then the immediate operation has to select the right operand 
(position = 1). If the binary is commutative, then any operand may be used. 

The query reports a set of records. In each record, binary refers to the Binary vertex, value refers to 
the value of the Const operand's value attribute, and edge refers to the the Dataflow edge that connects 
binary to the Const operand. The Const is deleted, and its value is pulled into the immediate operation. 

The interesting point is that the template graph specifies that the binary has to be replaced with a new 
vertex whose type is specified by a query instead of being fixed. Here, the type name is calculated by 
concatenating "Target" with the original binary's type name followed by "1". Since both the type name 
and the reference query are optional, a type name specified as query is denoted with a leading #. 

The value attribute is set to the value reported in each match record. The three dots (...) indicate that 
all other attributes that are equally defined for the type of the replaced binary and the new immediate 
binary have to be copied, e.g., the associative and commutative values. This saves one further operation 
call for transforming Cmp vertices which are usual binaries with an additional relation attribute. 

The next operation replaces MemoryNode vertices (Load/Store) that reference a SymConst to im- 
mediate target load/store vertices. 



MatchReplace (#"' Target" ++ tvpe/\/ame($ . memory) ++ "1 


" ' ' $ . memory ' 


symbol = ' $ . sym ' , . . . ) 


<= from m: \/{ MemoryNode } , 






df: ed^esFrom{ Da tafi ow } (m) , 






symConst: m — df— > Si {SymConst} 






reportSet rec(memory: m, sym : symConst . symbol , 


df: df) end; 





Again, the query returns a set of records. The memory node memory is replaced by a new immediate 
target memory node whose symbol attribute is set to the value of the original SymConst's symbol value. 
The Dataflow edge df connecting the original memory node to the SymConst is deleted. Again, further 
attribute values are copied. 

The two operations creating immediate target operations have created orphaned Const and SymConst 
vertices, i.e., vertices of these types that no other vertex depends on. Thus, they can be delete. 

Delete <^= from c: V{Const, SymConst} with inDegree{c) = reportSet c end; 

Finally, the transformation replaces all other vertices whose type has a target counterpart. 

MatchReplace (#'" Target" ++ typeName{$) ' '$' | ...) 

<= V{ " TargetNode , "TargetMemoryNode , "TargetMemoryNodel , 

"Block, "Argument, "Start, "End, "Phi, "Return, "Sync}; 
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The query returns the set of all vertices that are not of type TargetNode, TargetMemoryNode, Tar- 
getMemoryNodel, Block, Argument, Start, End, Phi, Return, or Sync. The former three exclude already 
transformed vertices, and the rest are nodes of types that don't have a different target type. 

Again, in the template graph the type of the new vertex is specified with a query. Since the match 
query evaluates to a set of vertices in contrast to a set of records, the variable $ holding the current match 
is just a vertex which will be replaced while copying attribute values from the replaced to the new vertex. 

3 Conclusion 

In this paper, the parts of the constant folding and and the complete instruction selection transforma- 
tion were explained. With respect to the evaluation criteria, both the Constant Folding as well as the 
Instruction Selection solution are complete and correct, at least for the provided test graphs. 

With respect to performance, all given graphs could be transformed in times between one and two 
seconds. However, running the constant folding transformation on the 100.000 nodes graph published 
shortly before the contest takes about six minutes. GReQL's set-based semantics of always calculating all 
matching elements has considerable influence especially on the Match Replace operation. This operation 
skips matches containing elements of previous matches, because the previous application might have 
changed them in a way that they would't match anymore. Thus, in the worst case any match except the 
first one has been calculated for nothing. 

With respect to conciseness, about 190 lines of code including comments and empty lines for three 
helpers and twelve operation calls is about as much as one would expect for the constant folding trans- 
formation. In contrast, the instruction selection transformation with its 4 operation calls subsuming to 42 
lines of code is very concise. 

Concerning purity, the transformations are specified completely in GReTL. But the language has 
been extended with three in-place operations appropriate for this task. In this respect, both judging the 
solution as pure as well as impure can be justified. Nevertheless, it demonstrates GReTL's extensibility 
which is a strength in its own respect. 
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A The Complete Solution 

In this appendix, the complete GReTL source code for the optional verifier, the constant folding trans- 
formation, and the instruction selection transformation is printed. 

A.l The Verifier 

The verifier is not part of the challenge, but especially when developing a transformation, a strict ver- 
ification helps to spot errors. GReTL does not distinguish between libraries and transformations. Any 
transformation like Verifier (Listing [T]) that does nothing except declaring helper functions can be con- 
sidered a library. When executing such a transformation, the helpers are made available to the calling 
transformation. 



transformation Verifier; 






checl<Validity () : — 






cour 


t(V{Start}) = 1 and coun t (V{ S t a rt B 1 oc k } ) = 1 


// 


{■'■J 


and 


count(V{End}) = 1 and count (V{ End B lock } ) = 1 


// 


(2) 


and 


(forall df: E{Dataflow}, 


// 


(3) 




hasType{ Block}(end Vert ex (df)) 








@ df . position = —1) 






and 


( forall n : VINode," Block} 


// 


(4) 




exists! df: edg;esFrom { Dataflow }( n ) 








@ df . position — —1 and has Type{ B 1 ock }( end Vertex ( d f ) ) 


) 




and 


( forall c: V{Const} 


// 


(5) 




c — >{Dataflow} tfte£/emen t (V{ S t a rt B 1 oc k }) ) 






and 


( forall 


// 


(6) 




phi : V{Ptni } , 








block: phi — >{Dataflow @ t h is Edge . p o s i t i o n =-1} <Si {Bl 


ock} 






@ outDegreej Dataflow }( ph i ) - 1 = 


// 


(6.1) 




outDegree{ Controlflow}( block) 








and ( forall 


// 


(6.2) 




posNo: llst(0.. outDegree{ Controlflow}( block) 


- 1) 






(exists! phiEdge: edgesFrom { D a ta fl ow }( p h i ) 








@ p h i Ed ge . p o s i t i o n = posNo) 








and (exists! blockEdge : 








edgesFrom {Controlflow}( block) 








@ blockEdge. position = posNo))) 






and 


(forall block: V{ Block , ~ EndBlock} 


// 


(7) 




/nDe^ree ( block ) > 0) 






and 


(forall v: V degree(v) > 0); 


// 


(8) 



Listing 1 : The verifier as GReTL helper 



In line 3, a GReQL helper named checkValidity() with no parameters is defined. It checks for eight 
constraints marked with numbered comments that must hold for the current graph. 

(1) There must be exactly one Start and one StartBlock. 

(2) There must be exactly one End and one EndBlock. 

(3) For all Dataflow edges pointing to a Block, the position attribute has to be set to -1. 

(4) For all Node vertices with the exception of Block vertices, there exists exactly one outgoing Dataflow 
edge with position set to -1 and leading to a Block, i.e., any node is contained in exactly one block. 

(5) All Const vertices are contained in the single StartBlock. 

(6) Phi vertices have the correct structure: 

(6.1) Phi vertices have as many operand Dataflow edges as their containing Block has Controlflow 
predecessors. 
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(6.2) For any position number between and the number of Controlflow predecessors of the Phi's 
block minus one, there exists exactly one Phi argument edge with that position number and 
exactly one control flow predecessor with that position number. 

(7) There are no empty blocks. 

(8) There are no isolated vertices. 

Because the helper is a conjunction of predicates, its result is a boolean value. The transformations 
discussed in the next sections are asserting that the helper returns true as first command (to ensure the 
given graph is correct) and as last command (to ensure the transformation produced a valid result). 



A.2 The Constant Folding Transformation 

In the following, the complete GReTL source code of the Constant Folding transformation is shown. 



transformation Consta n t Fold i ng ; 

// "import" the c h e c kV a I i d i t y ( ) helper 
ExecuteTrans formation " t ra nsf orms / v e r i f i e r . g r et 1' 



Assert <= c h ec kVa I i d i ty ( ) ; 

// Bind the single Sta rtBlock to a variable 
startBlock := t/)e£/ement(V{ Sta rt B lock }) ; 



// Evaluates the given 
e va I u a t e B I n a r y ( ) :— us 
has Type { Add }( bin ) 
has Type { Sub } ( b i n ) 
/7as7ype{Mul}( bin ) 
has Type{ D i v } ( b i n ) 
/7asType{Mod}( bin ) 
has Type{ S h I } ( b i n ) 
has Type{ Shr}(bin) 
has Type{ Shrs}(bin) 
has Type {And } ( b i n ) 
has Type { Or } (bin) 
hasType{ Eor}( bin ) 
hasType{Cmp}{ bin ) 
(bin. relation ; 
bin. relation : 
bin. relation : 
bin. relation ; 
bin. relation : 
bin. relation : 
bin. relation 
bin. relation 



Binary 
ng bin, 
I va I + 
Ival - 
I V a I * 
(let d 
Ival % 
bitOp ( 
bitOp ( 
bitOp( 
bitOp ("AND" 
bitOp ("OR" , 
bitOp("XOR' 



rva I . 



with Ival and 

Ival , r va I : 
f r V a I 
- r V a I 
* r V a I 

d := Ival / rval 
'/o rval 

SHIFT_LEFT" , Ival 



in 



d < ? ceil (d) : floor (d)) 

rval) 



UNSIGNED_SHIFT_RIGHT" , Ival, rval 



SHIFT_RIGHT 
Ival , 
Ival , 
Ival , 



" , Ival 
rval) 

rval) 
rval) 



rval 



error{" Don ' t 
error(" Don't know 



= "GREATER" 
= " GREATER_EQUALS" 
= "LESS" 
= "EQUAL" 
= "NOT_EQUAL" 
= "LESS.EQUAL" 
= "TRUE" 
= "FALSE" 
know how to handle 
how to handle " ++ 



( Ival 
( Ival 
( Ival 
( Ival 
( Ival 
( Ival 
1 


" ++ bin 
bin ) ; 



> rval 
>= rval 
< rval 
= rval 
O rval 
<= rval 



0) 
0) 
0) 
0) 
0) 
0) 



relation )) 



// Sorts the given dataflows by the value of their position attribute. 
s o r t B y P o s i t i o n ( ) :— using dataflows: 

let posMap := from i: li s t ( .. count ( d a ta flows ) — 1) 

reportMap dataflows [ i ] . position — > dataflows [ i ] end , 
sortedKeys := so rt ( /teySet ( posMap ) ) 
in from i : sortedKeys 

reportSet posMap[i] end; 



// A helper that returns all non— containment dataflows of a node. 
// dataflows where position is not —1. 
nonContainmentDfs () := using node: 

from e: edg'esF/-om{ Dataflow }( node ) 

witii e. position O —1 



That means, 
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71 
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81 
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reportSet e end; 

// Perform the contained transformations as long as one was applicable 
Iterativel V 

// Replace associative , commutative Binaries of form ((x + y) -h 1) with ((x 
// 1) + y), that is , pull up constants. 
Iteratively MatchReplace bl ( ' $ . bl ' ) , b2 ( ' $ . b2 ' ) , 

bl — >{'$.dfl'} b2 — >{'$.df3'} ('$.c'), 
b2 — >{'$.df4 '} ( 'S.y') , 
bl — >{'$. df2 '} ( '$.x ■) 
<= from bl: V{Add, Mul}, 

dfl , df2 : nonConta in mentDfs ( bl ) , 

b2: bl — dfl-> & {Add, Mul @ type(bl) = type( thisVertex )} , 
df3, df4: nonContainmentDfs(b2) 
with dfl O df2 and df3 <> df4 

// Used only by bl + the containment Dataflow 
and /nDeg-ree{ Dataflow }( b2 ) = 2 
and has Type{ Const } ( endVertex ( df2 ) ) 
and no t ( /iasType{ Const }( X ) ) 
reportSet rec(bl: bl , b2 : b2 , x: x, c: theElement{bl — df2->), 

y: y, dfl: dfl, df2 : df2 , dfS : df3 , df4 : df4) end 
where x := theElement{b2 — df3— >), 
y :— theElement{b2 — df4->);; 

// Replace Binary with 2 Consts with a single Const of the result. Do 

// iteration here, cause that operation is likely to produce another match 

// immediately . 

Iteratively MatchReplace ('startBlock ') < — {Dataflow | position = ' — 1'} 

(Const '$.op' I value = '$. value') 
<= from binOp: V{ Binary} 

with /7asType{ Const }( I con St ) and hasrype{ Const }( rconst ) 
reportSet rec(op: binOp , 

value: eva I u a te B i n a ry ( binOp , Iconst . value , rconst. value 
edges: ec/g-esFrom ( binOp ) ) end 
where argEdges := sort By Pos i t i o n ( nonConta inmentDfs ( binOp )) , 
Iconst := end\/ertex( argEdges [0] ) , 
rconst := endVertex ( a rg Edges [ 1 ]); ; 

// Replace unary ops (i.e., Not) with the value 

Iteratively MatchReplace ('startBlock ') < — {Dataflow | position = ' — 1'} 

(Const '$.op' I value = '$. value') 

<= from uniOp: \/{Not} 

with hasType{ Const } ( endVertex{ a rgEdge ) ) 
reportSet rec(op: uniOp , 

value: bitOp("NOT", end\/ertex( argEdge ). va I ue ) , 

edges: edg^esFrom ( uniOp ) ) end 
where argEdge := theE/ement( nonContainmentDfs ( uniOp ) ) ; ; 

// Remove unused Consts 

Delete <^= from c: V{ Const} with inDegree{c) = reportSet c end; 

// Merge duplicate Consts into one for each value. 
MergeVertices <= from const: V{Const} 

reportMap const — > from d: V{Const} 

with d. value = const. value 

and d O const 
reportSet d end 

end ; 

// Remove duplicate edges from StartBlock to Consts. 
Delete <= from c: \/{Const} 

reportSet d if fe re n ce ( dfs , set(dfs[0])) end 

where dfs := edg:esFrom{ Dataflow }( c ) ; 

// Replace Cond nodes depending only on a Const with an unconditional Jmp. 



124 



Solving the TTC 201 1 Compiler Optimization Case with GReTL 



MatchReplace ('$. block ) < — {'$.df'} (Jmp) < — {Controlflow} ('$. target') 
<= from cond : \/{Cond} 

with not isEmpty{cond — >{Dataflow} &i {Const}) 
reportSet rec(cond: cond, // the Cond 

df: blockTup[0] , // the Dataflow to the containing Block 

block: blockTup[l] , // the containing Blocl< 
cf : t a rget T u p [ ] , // the True/False edge to the target 

target : targetTup [1] , // the target of the Cond 
edges: edg:esConnectecy ( cond ) ) end 
where const := tfteE/ement ( cond — >{Dataflow} Si {Const}), 

blockTup := theElement{from e: erfg'esFrom{ Dataflow }( cond ) 

with e. position = —1 
reportSet e, endVertex{e) end), 
targetTup := t/7eE/ement(from e: edg^esTo{ Con t rolf I ow } ( cond ) 

with const. value = ? /7asType{ Fa I se }{ e ) 

/)asType{ True }( e ) 
reportSet e, sta rtVertex (e) end); 

// Now delete any node that has no outgoing Dataflow recursively 
Iterati vel V Delete <= from node: \/{ " S t a rt B I oc k } 

with outDeg^ree { node ) = 

reportSet node end ; ; 

// Remove the superfluous operand edges of Phis 

Delete <== from phi: V{Phi}, opEdge: edgesFrom{ Da taf low }( ph i ) 

with opEdge . position <> —1 

and f70t( conta /ns(predBlockCfPositions, opEdge. position)) 

reportSet opEdge end 

where predBlock ;= t/7e£/ement( phi — >{Dataflow thisEdge . pos i t i o n = — 1}), 
pred BlockCfPositions := from df: edg'esFrom{ Co ntrolf low }( pred Block ) 

reportSet df. position end; 

// Renumber Phi operand edges and the corresponding block predecessor edges. 
MatchReplace ('S.phiOperand') < — {'S.phiOpEdge' | position = '$. position'} ('$.phi'), 
( ' $ . blockPred ' ) < — {'$ . blockCfEdge ' | position = '$. posit io n ' } ('$. block 
<= from phi: V{Phi}, i: I i s t ( .. count( blockEdges ) - 1) 
reportSet rec ( phiOperand : end\/ertex( phiOpEdges [ i ] ) , 
phiOpEdge: phiOpEdges [ i ] , 
position: i , 
phi: phi, 
block: block , 

blockCfEdge : blockEdges [ i ] , 

blockPred: en d Vertex ( b I oc k Ed ges [ i ]) ) end 
where phiOpEdges := so rt B y P os i t i o n ( non Conta i nmentDfs ( p h i )) , 

block := the£/emef) t ( p h i — >{Dataflow thisEdge . pos i t i o n = —1}), 
blockEdges := so rt By P os i t i o n ( edg^esFrom{ C o n t ro I fi ow }( b I oc k )) ; 

// Remove Phis with only one argument 
MatchReplace ('$.arg') < — {'$ . depEdge ' } ('$.dep') 
<= from phi : V{ Phi} 

with count( a rgEdges ) = 1 

reportSet rec(arg: t/je£/ement( phi — argEdge — >), 
depEdge : userEdge , 

dep : th eE/emen t ( ph i <— userEdge ), 

phi: phi, 

edges: edg^esConnected( ph i ) ) end 



where argEdges 
argEdge 
userEdge 



nonContainmentDfs( phi 
argEdges [0] , 

theElement { edges To{ Dataflow}(phi)); 



// Remove Blocks that contain only a single Jmp 
MatchReplace ('S.pred') < — {'$. pred Edge ' } ('$. target') 
<= from block: V{Block}, jmp: V{Jmp} 

with block < — {Dataflow t hisEdge . pos i t i o n = —1} jmp 
and i n Degree (h\ock) = 1 
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reportSet rec(pred: theElement{b\ock — >{ Co n t rol f I o w } ) , 

predEdge: theElement { edgesFrom{ Controlflow}( block )) 



ta rget 
edgesl 
edges2 



t he E I e m e nt {]mp < — { C o n t ro I f I o w } ) , 
edgesConnected (block) , 
edgesCon nected {imp) , 



block : block ) end ; 

; // End outer Iteratively 

// Finally , check if still everything 's correct . 
Assert <= c h ec kVa I i d i ty ( ) ; 



A.3 The Instruction Selection Transformation 

In the following, the complete GReTL source code of the Instruction Selection transformation is shown. 

transformation I n s t r u c t i o n S e I ec t i o n ; 

// "import" and execute the c h e c kV a I i d i t y ( ) helper 
ExecuteTrans formation " t ra n sf orms / v e r i f i e r . g ret I " ; 
Assert <= checkValidity (); 

// Transform all Binaries with at least one Const to an immediate TargetBinary 
// operation. 

MatchReplace (#"' Target" ++ typeName{S . binary) ++ "|"' '$.binary'| value ='$.value', ...) 
<= from b: V{ Binary} 

with count( constEdges ) > 
reportSet rec(binary: b, 

value: end Uert ex (constEdges[0]). value , 
edge: constEdges [0] ) end 
wliere constEdges := from e: edgesF/-om{ Dataflow}(b) 
with (b . commutative = false ? 

// For nan— commutative binary ops, we have to chose the 
// dataflow on position 1, i.e., the second argument 
e. position = 1 

// ... else anything except —1 is ok. 
: e . p o s i t i o n <> — 1 ) 
and hasType{Cor\5t}(endVertex{e)) 
reportSet e end ; 

// Transform Load/Store with SymConsts to Ta rget Load I / Ta rget Storel . 

MatchReplace (#"'Target" ++ typeft/ame($ . memory) ++"1"' '$. memory' | symbol = ' $ . sym ' , ...) 
<= from m: V{MemoryNode} , 

df: edgesFrom{ Dataflow } (m) , 
symConst: m — df— > &i {SymConst} 
reportSet rec(memory: m, sym: symConst . symbol , df: df) end; 

// Delete unused Const/SymConst vertices . 

Delete <= from c: V{Const, SymConst} with inDegree(c) = reportSet c end; 

// Transform the rest of the elements . TargetMemoryNode and TargetMemoryNodel 
// have to be excluded explicitly , because they are not derived from TargetNode . 
MatchReplace (#"' Target" ++ typeName{$)' '$' | ...) 

<= V{ " Ta rget N ode , "TargetMemoryNode , "TargetMemoryNodel , 

"Block, "Argument, "Start, "End, "Phi, "Return, "Sync}; 

// Finally , check if still everything 's correct. 
Assert <= ch ec kVa I i d i ty ( ) ; 



